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ABSTRACT 

Minehunting  is  a  complex  process  involving  detection  and  classification  of  contacts 
using  sonar  and  the  subsequent  identification  and  disposal  of  mines,  generally  using  a 
remotely  operated  underwater  vehicle  (ROV).  However,  making  suitable  assumptions, 
minehunfing  can  be  approximated  by  a  series  of  connected  events  and  thus  made 
amenable  to  modelling  using  the  technique  of  discrete-event  simulation.  In  this  report, 
a  discrete-event  minehunting  simulation  model  is  described  together  with  instructions 
for  its  operation.  The  model  can  be  applied  to  evaluate  the  effectiveness  of 
minehunting  systems  for  a  given  operational  scenario  and  also  to  investigate  new 
concepts. 
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1.  Introduction 

Modelling  and  simulation  can  be  applied  both  to  predict  the  behaviour  of  existing 
mine  warfare  systems  in  operational  scenarios  (and  thus  assist  tactical  decision 
making)  and  also  to  investigate  new  mine  countermeasure  (MCM)  and  mining 
concepts.  Because  of  the  expense  and  difficulties  involved  in  conducting  trials,  this  is 
frequently  a  useful  method  for  studying  mine  warfare  systems  under  a  variety  of 
conditions. 

The  Royal  Australian  Navy  (RAN)  is  establishing  a  dedicated  Mine  Warfare  Systems 
Centre  (MWSC)  to  provide  the  prime  focus  for  all  operational  aspects  of  RAN  mine 
warfare  activities  [1].  Modelling  and  simulation  will  form  an  integral  part  of  the 
MWSC's  decision  support  systems  required  to  enable  optimum  use  of  limited  MCM 
assets.  A  hierarchy  of  models  is  required  ranging  across  four  levels: 

(1)  Level  1:  Single  vessel  against  a  single  mine 

(2)  Level  2:  Single  vessel  against  many  mines  (minehunting,  minesweeping) 

(3)  Level  3:  Several  vessels  against  many  mines  (eg.  MCM  force,  convoy) 

(4)  Level  4:  Several  MCM  forces  against  several  minefields 

Models  both  for  rapid  response  and  detailed  studies  are  required.  The  rapid 
response  models  will  use  analytical  techniques  whereas  the  detailed  models  will 
employ  simulation  techniques.  These  model  variants  are  referred  to  as  mode  1  and 
mode  2  respectively. 

Level  2  simulation  models  for  minesweeping,  minehunting,  and  minefield  planning 
have  been  developed  and  reported  previously  [2-4].  The  existing  documentation  of  the 
minehunting  model  (MHUNT)  [3]  covers  the  principles  and  applications  of 
minehunting  simulation.  This  report  comprises  a  detailed  specification  of  the  MHUNT 
model  and  the  information  required  to  run  it. 

The  MHUNT  model  has  been  used  by  Maritime  Operations  Division,  AMRL,  to 
evaluate  the  operational  effectiveness  of  minehimting  systems  being  considered  by  the 
RAN's  Minehunter  Coastal  (MHC)  Project  [5].  It  is  expected  that  the  model,  or  at  least 
a  modified  version  of  it,  will  be  incorporated  into  the  MWSC. 
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2.  Model  Description 


2.1  Model  Overview 

As  explained  in  [3],  for  simulation  purposes  the  minehunting  procedure  is  reduced  to  a 
series  of  connected,  discrete  events  such  as  mine  detection  and  classification.  The 
MHUNT  model  operates  by  first  defining  a  minefield  populated  with  a  given  number 
of  mines  and  non-mines.  The  minehunter  is  constrained  to  traverse  this  minefield  on  a 
given  set  of  tracks  and  each  hunter/object  encounter  is  evaluated  using  Monte  Carlo 
techniques.  If  a  mine  is  detected  and  also  classified  correctly  a  Remotely  Operated 
Vehicle  (ROV)  is  deployed  to  identify  and  dispose  of  the  mine.  For  a  given  tactic  of 
track  spacing  and  runs  per  track  the  model  calculates  clearance  level  and  other 
measures  of  effectiveness  (MOE)  defined  for  a  minehunting  system.  Many  replications 
of  a  minefield  traversal  are  performed  to  determine  average  MOEs  for  a  given  scenario. 

The  main  submodels  comprising  the  model  are  illustrated  in  Figure  1. 


Figure  1:  Submodels  for  minehuniing  model 


2.1.1  Initialisation  and  Minefield  Submodels 


The  Initialisation  submodel  receives  the  input  data  needed  for  a  simulation  run,  either 
from  the  keyboard  or  a  file  stored  on  disk.  This  data  includes  the  number  of 
replications  in  each  simulation  run.  For  each  replication,  the  Initialization  Submodel 
calls  successively  the  Minefield  Submodel,  the  MCM  Submodel  (comprising  the 
MCMV  Submodel,  Sonar  Submodel,  ROV  Submodel  and  Damage  Submodel)  and, 
optionally,  the  Graphics  Submodel.  The  Minefield  Submodel  declares  the  minefield  to 
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be  cleared,  by  assigning  a  specified  number  of  mines  and  non-mines  to  locations  in  a 
rectangular  area. 


2.1.2  MCMV  Submodel 

The  MCMV  Submodel  determines  the  lap  tracks  that  the  MCMV  will  traverse,  which 
are  evenly-spaced  paths  parallel  to  the  minefield  axis  and  connected  by  semicircles  at 
each  end.  The  spacings  are  calculated  according  to  the  track  spacing  tactic  included  in 
the  input  data.  The  MCMV  Submodel  then  simulates  the  movement  of  the  MCMV 
along  each  track,  and  diversions  off  the  track  when  contacts  (mines  or  non-mines)  are 
encountered. 


2.1.3  Sonar,  ROV  and  Damage  Submodels 

The  Sonar  Submodel  calculates  the  sonar  detection  and  classification  envelopes  as  the 
MCMV  moves  along  the  track,  and  determines  whether  each  contact  encountered  is 
detected  and  classified.  Contacts  detected  and  classified  as  mine  are  input  to  the  ROV 
Submodel,  which  simulates  the  movement  of  the  ROV  to  a  point  sufficiently  near  the 
contact  to  enable  it  to  be  identified.  If  a  contact  is  identified  as  a  mine,  the  ROV 
Submodel  then  simulates  its  disposal  by  means  of  a  mine  disposal  charge  (MDC).  The 
Damage  Submodel  determines  whether  the  MCMV  passes  within  the  actuation  and 
damage  radii  of  any  mine  encountered,  and  whether  it  is  damaged.  If  the  MCMV  is 
damaged,  the  replication  is  terminated. 


2.1.4  Graphics  Submodel 

The  Graphics  Submodel  may  be  called  after  a  single  replication  run,  and  plots  the 
minefield  and  paths  of  the  MCMV  and  ROV  in  their  transit  through  the  minefield.  The 
results  of  each  encounter  between  the  MCMV  and  a  contact  are  indicated  on  the  plot. 


2.2  Model  Versions 

The  model  was  initially  coded  in  FORTRAN  77  for  the  VAX/VMS  environment.  The 
Simpleplot  graphics  library  was  used  to  provide  graphical  output  of  a  single  minefield 
traversal.  Random  numbers  required  for  event  selection  were  provided  either  by 
internal  VAX  FORTRAN  functions  or  NAG  library  functions. 

The  model  was  subsequently  ported  to  the  IBM  PC  MS-DOS  environment  for  greater 
convenience.  Various  enhancements  were  made  to  improve  the  model's  functionality. 
In  the  remainder  of  this  report,  the  original  VAX  version  of  the  model  will  be  termed 
MHUNT  Version  1  and  the  enhanced  version  MHUNT  Version  2.  The  enhancements 
incorporated  in  MHUNT  Version  2  are  included  in  the  overall  model  specification. 
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The  main  enhancement  in  MHUNT  Version  2  is  the  adoption  of  a  parallel  process 
architecture.  Version  1  comprised  a  single  minehunting  process,  i.e.  a  sequence  of 
events  and  states  executed  in  a  fixed  order.  The  ROV  was  assumed  to  be  continuously 
available,  and  neither  those  activities  associated  with  turning  it  around  (changing  its 
battery,  charging  flat  batteries,  loading  an  MDC,  etc.)  nor  the  availability  and  use 
during  MCM  operations  of  more  than  one  (typically  two  per  MCMV)  ROV  were 
considered.  These  assumptions  may  fail  in  areas  of  high  mine  density  where  many 
ROV  runs  are  required  to  identify  mine-like  objects.  Thus  it  was  decided  to  reorganise 
the  model  to  allow  the  ROV  to  be  modelled  as  a  separate  process  running  concurrently, 
or  in  parallel,  to  the  MCMV. 

Version  2  is  organised  into  multiple  parallel  processes.  In  order  to  execute  the  events 
from  these  processes,  a  linked  list  of  future  events  was  also  adopted.  The  model  has 
five  processes,  which  respectively  describe  the  MCMV,  MDC,  ROV  battery  charger, 
spare  ROV  and  next  ROV  to  be  used  for  mine  disposal. 


2.3  Model  Specification 

The  MHUNT  model  was  specified  by  means  of  Clymer's  directed  graph  notation  [6],  a 
form  of  state  transition  diagram.  It  also  incorporates  Clymer's  event  management 
software  for  controlling  its  dynamic  behaviour.  This  is  a  collection  of  Fortran 
subroutines,  some  of  which  have  to  be  tailored  to  each  application  software  system, 
while  others  can  be  incorporated  unchanged.  A  detailed  description  of  Clymer's 
methodology  is  provided  in  Annex  A  and  short  descriptions  of  each  module  are 
provided  in  Annex  B.  Clymer's  method  was  adopted  for  the  following  reasons: 

•  Version  1  of  the  model  had  been  written  in  Fortran  with  a  single  process  and 
without  a  future  events  list.  The  model  was  needed  urgently  for  the  MHC 
Effectiveness  Study  [5],  which  meant  there  was  insufficient  time  to  completely 
redevelop  the  model  using  object-oriented  design  techniques.  The  enhancements 
subsequently  incorporated  into  Version  2  were,  however,  judged  to  be  essential. 
Clymer's  directed  graph  notation  is  relatively  simple  and  its  concept  of  parallel, 
interacting  processes  incorporates  some  of  the  characteristics  of  concurrent  objects 
which  would  be  obtained  using  a  proper  object-oriented  design. 

•  Clymer's  book  [6]  is  accompanied  by  a  disk  containing  event  management  software, 
written  in  Fortran,  which  supports  his  method.  No  other  such  software  was 
available  at  low  cost,  and  for  the  analysts  concerned  (the  authors)  to  write  their  own 
would  have  been  both  time  consuming  and  unnecessary. 


2.3.1  Directed  Graph  Specification  of  the  MHUNT  Model 

The  complete  model  specification  is  shown  in  Figure  2.  This  section  describes  the 
processes  shown. 
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Clymer's  notation  is  generally  used,  although  a  minor  change  has  been  introduced: 
some  states  have  been  grouped  into  superstates,  which  are  states  at  a  higher  level  of 
abstraction  embodying  the  behaviour  of  their  substates.  This  change  was  introduced 
when  the  Version  2  model  was  being  constructed  by  merging  the  Version  1  model  with 
a  prototype  model  built  using  Clymer's  methodology:  some  of  the  states  in  the 
prototype  were  modelled  in  a  simplified  way,  whereas  the  Version  1  model  had 
developed  these  states  in  more  detail,  so  that  in  the  Version  2  model  they  became 
superstates.  All  the  states  in  a  superstate  were  given  the  same  name,  and  are  indicated 
as  in  the  following  example: 


Figure  3:  Superstate  for  search  for  contact  process 


In  the  above  diagram,  the  states  denoted  [SC]  are  reaction-time  states,  whereas  the 
states  denoted  SC  are  stages  in  the  computation  and  do  not  correspond  to  external 
system  behaviour  (a  reaction  time  or  wait  time). 

There  are  five  parallel  processes  depicted  in  Figure  2.  To  distinguish  them  on  the 
diagram,  each  process  has  its  states  drawn  differently  as  shown  in  the  legend. 


Process  1:-  MCMVfPOV  Process 

This  is  the  main  process  corresponding  to  all  the  states  and  events  associated  with 
minehunting  operations  i.e.  excluding  ROV  turnaround  and  ROV  battery  charging. 
From  event  2  (<E2>  MCMV  arrives  at  operational  area)  until  event  5  (<E5>  ROV 
becomes  available)  the  MCMV  is  the  active  component,  whereas  from  event  5  until 
event  10  (<E10>  ROV  recovery  ends)  the  ROV  is  the  active  component.  Split  and 
assemble  events  control  the  transition  from  active  MCMV/passive  ROV  to  active 
ROV/passive  MCMV.  The  states  in  process  1  are  as  follows: 
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IP 

In  Port 

TO 

Transit  to  Operational  Area 

SC 

Searching  for  Contact 

CC 

Classifying  Contact 

WRO 

Waiting  for  ROV 

HR 

Moving  to  Hover  Radius 

VC 

In  Vicinity  of  Contact 

IC 

Identifying  Contact 

LC 

Laying  Charge 

RR 

Recovering  ROV 

WAD 

Waiting  for  Arming  Delay 

RT 

Returning  to  Track 

SD 

Moving  to  Safe  Distance 

FC 

Firing  Charge 

RP 

Returning  to  Port 

WCE 

Waiting  for  Minehunting  Cycle  to  End 

IP 

In  Port 

Process  2:  MDC 

This  is  a  minor  parallel  process  which  represents  the  circumstance  that  event  12 
(<E12>MCMV  starts  to  move  to  safe  distance)  carmot  occur  until  after  the  ROV  is 
recovered  and  the  MDC  arming  delay  finishes,  whichever  is  the  longer.  The  states  in 
process  2  are  as  follows; 

AD  Waiting  for  Arming  Delay 

WRR  Waiting  for  ROV  Recovery 


Process  3:  Battery  Charger  (#1  or  #2) 

This  is  a  parallel  process  representing  the  charging  of  flat  batteries  removed  from 
ROVs  when  they  are  recovered  after  operations.  One  or  two  battery  chargers  are 
allowed,  and  since  if  two  are  used  they  both  follow  the  same  process,  only  one  process 
is  shown  in  the  parallel  process  model  (Figure  2).  The  states  in  process  3  are  as 
follows: 

WFB  Waiting  for  Flat  Battery 

CB  Charging  Battery 

13  Process  3  Idle 


Process  4:  Spare  ROV 

This  is  a  parallel  process  representing  the  turnaround  of  one  of  the  two  ROVs.  In  the 
model,  a  decision  as  to  which  of  the  two  ROVs  will  be  used  on  the  next  ROV  operation 
is  made  after  an  ROV  is  recovered  from  the  water.  The  decision  logic,  encoded  in  the 
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model,  takes  into  account  the  expected  battery  life  remaining  in  both  ROV  installed 
batteries  and  other  factors.  The  two  actual  ROVs  can  switch  between  the  Next  ROV 
Process  and  Spare  ROV  Process  when  this  decision  is  made.  The  states  in  process  4  are 
as  follows: 


WDS 

Waiting  for  a  Decision  on  Spare  ROV 

WRBl 

Waiting  for  a  Replacement  Battery 

TAl 

Spare  ROV  in  Turnaround 

14 

Process  4  Idle 

Process  5:  Next  ROV 

This  process  is  similar  to  the  Spare  ROV  Process,  but  has  minor  differences  which 

resulted  in  it  being  treated  as  a  separate  process.  The  states  in  process  5  are  as  follows: 

MD  A  Management.Decision  (on  next  ROV)  being  made 

WRB2  Waiting  for  a  Replacement  Battery 

TA2  Next  ROV  in  Turnaround 

WME  Waiting  for  next  Mine  Classification  Event 

The  following  are  split  events: 

•  Event  2,  arrival  at  the  operational  area,  as  the  hitherto  single  MCMV/ROV  Process 
then  splits  into  three:  the  Battery  Charger  Process,  the  Spare  ROV  Process  and  the 
ongoing  MCMV/ROV  process. 

•  Event  9,  MDC  laying  ends,  as  the  MCMV/ROV  Process  then  runs  in  parallel  to  the 
MDC  Process  until  either  the  ROV  is  recovered  or  the  MDC  arming  delay  ends, 
whichever  is  the  later. 

•  Event  10,  ROV  recovery  ends,  as  the  MCMV/ROV  Process  then  runs  in  parallel 
with  the  Next  ROV  Process  until  either  the  next  ROV  becomes  available  after 
turnaround  or  a  contact  is  classified  as  a  mine  and  hence  the  next  ROV  is  required, 
whichever  is  the  later. 

The  assemble  events  are: 

•  Event  12,  MCMV  starts  to  move  to  safe  distance,  is  the  assemble  event  for  the  MDC 
Process,  i.e.  it  ceases  to  operate  after  event  12. 

•  Event  5,  ROV  becomes  available,  is  the  assemble  event  for  Next  ROV  Process.  It 
cannot  be  executed  until  the  next  ROV  is  available  after  turnaround  (i.e.  in  the  state 
of  waiting  for  the  next  mine  classification  event)  and  a  contact  has  been  classified  as 
a  mine  (i.e.  the  MCMV  is  in  the  state  of  waiting  for  the  ROV  to  become  available). 

•  Event  25,  minehunting  cycle  ends,  is  the  assemble  event  for  all  three  then  active 
processes.  It  cannot  be  executed  until  the  battery  charger(s)  have  finished  charging 
all  flat  batteries,  the  spare  ROV  has  finished  its  turnaround,  and  the  MCMV  has 
reached  port  and  is  in  the  state  of  waiting  for  the  other  processes  to  finish. 
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Flow  charts  of  the  key  events  in  the  MHUNT  model  are  given  at  Annex  C. 

2.4  Other  Model  Enhancements 

Further  enhancements  were  made  to  the  model.  These  are  described  in  the  following 
subsections. 


2.4.1  Sonar  Performance 

The  initial  model  used  rectangular  parameters  for  detection  of  contacts.  If  a  contact 
was  within  a  sector  defined  by  the  sonar  range  and  detection  width  it  had  a  constant 
probability  of  being  detected.  The  enhanced  model  includes  the  option  of  using  sonar 
detection  data  from  a  minehunting  sonar  model  such  as  MINERAY  [7].  It  reads  an 
input  data  file  containing  a  set  of  ranges  with  the  cumulative  detection  probability 
shape  for  each  range  as  shown  in  figure  4  below: 


Figure  4:  Sonar  cumulative  detection  probability 


It  also  reads  the  minimum  and  maximum  detection  ranges,  the  detection  range  for 
90%  probability,  the  sector  angle,  and  the  sector  edge  reduction  factor.  The 
probabilities  for  the  given  range  are  scaled  to  this  shape. 

Across  the  track,  the  detection  probability  is  represented  by  a  trapezoid  shape  as 
shown  in  Figure  5  below.  The  maximum  detection  width  is  given  by 

Maximum  detection  width  =  2*  Detection  Range  for  90%  probability  *  sin(Qf2),  (1) 
where  9  is  the  sector  angle  and  the  minimum  detection  width  is  given  by 
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Minimum  detection  width  =  (I-t])  *  maximum  detection  width  (2) 

where  Ti  is  the  edge  reduction  factor  which  allows  for  the  reduction  of  detection 
probability  at  the  edge  of  the  sonar  sector  due  primarily  to  the  limited  sonar  coverage 
in  this  region  and  operator  factors.  For  cross-channel  distances  less  than  the  minimum 
detection  width,  the  cumulative  detection  probability  at  a  given  range  is  determined  by 
scaling  from  Figure  4  as  described.  Within  the  interim  region  between  minimum  and 
maximum  detection  width  the  detection  probability  is  determined  using  linear 
interpolation;  beyond  maximum  detection  width  the  detection  probability  is  set  to 
zero. 


Direction  of  A( 

i 

ivance 

/ Minimum  Detec 

Detection  / 

Probability  / 

/  Maximum  Del 

ion  Width  \ 

action  Width  \ 

Across  Track  Distance 

Figure  5:  Detection  probability  as  a  function  of  cross  track  distance 


2.4.2  Tactics 

In  Version  1  of  the  model  the  only  minehimting  tactic  allowed  was  the  progressive 
hxmting  sequence  in  which  tracks  were  progressively  hunted  from  one  side  of  the 
channel  to  the  other.  This  was  changed  from  the  initial  version  to  include  the  effect  of 
navigational  error  on  track  spacing.  Thus  the  number  of  tracks  is  determined  by 

N  =  C/(D-2a)  (3) 

where  C  is  the  channel  width,  D  is  the  detection  width  and  a  is  the  navigational  error. 
N  is  roimded  to  the  next  higher  integer.  The  track  spacing  is  then  computed  from 

d  =  C/N  (4) 

Figure  6  shows  an  example  of  this  tactic  for  a  channel  width  of  1000  m  and  a  detection 
width  of  about  550  m  with  navigational  error  ignored. 
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Figure  6:  Minimum  ejfort  hunting  tactic  using  progressive  sequence  across  track 

This  tactic  can  be  designated  as  a  minimum  effort  tactic  which  attempts  to  produce 
uniform  clearance  across  the  whole  channel  since  the  fewest  possible  tracks  are  used. 
Effort  can  be  simplistically  considered  as  the  sum  of  the  lap  transit  time  J(NL/v), 
where  J  is  the  number  of  runs  per  track,  L  is  the  track  length  and  v  the  mean  speed  of 
advance,  and  the  mine  prosecution  time  (MTp)  where  M  mines  are  prosecuted  each 
taking  time  Tp.  For  a  given  clearance  level  the  same  number  of  mines  will  be 
prosecuted  so  that  the  tactic  which  provides  the  minimum  passes  across  the  minefield 
will  require  minimum  effort. 

In  Version  2  an  additional  minehimting  tactic  has  been  added  [8].  This  tactic  allows 
the  MCMV  to  hunt  in  xmcleared  waters  only  for  the  first  track  which  is  m  the  centre  of 
the  channel.  Subsequent  tracks  are  then  hunted  within  the  cleared  area  working 
outwards  from  the  centre  track.  Each  track  is  placed  a  distance  (2a  +51  from  the  outer 
edge  of  the  cleared  area  where  6  is  the  MCMV's  hover  distance.  The  track  spacing  is 
determined  by: 

d  =  D/2 -2a- 5  (5) 

and  the  number  of  tracks  is  given  by: 
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N  =  2(C/2d)  +  l  (6) 

where  {C/2d)  is  truncated  to  the  nearest  integer.  Figure  7  shows  an  example  of  this 
tactic  for  a  minefield  width  of  1000  m,  detection  width  of  500  m,  zero  navigational 
error  and  hover  distance  of  100  m.  Equation  (6)  predicts  a  total  of  7  tracks,  the  first 
down  the  centre  of  the  channel,  the  second  at  a  cross-channel  distance  of  150  m,  the 
third  at  150  m  and  so  on.  This  tactic  ensures  considerable  overlap  between  tracks. 


Figure  7:  Minimum  risk  hunting  tactic 

This  tactic  can  be  considered  as  minimum  risk  since  only  on  the  first  run  is  the 
minehimter  hunting  in  imcleared  waters.  This  assumes  that  there  are  mines 
throughout  the  region  and  not  only  in  the  chaimel.  If  there  were  mines  only  in  the 
channel  then  a  preferred  tactic  would  be  to  hunt  along  a  track  outside  the  channel  for 
the  first  lap,  then  to  hunt  sequentially  inside  the  channel  so  that  the  MCMV  is  always 
in  hunted  waters. 


2.4.3  Damage  to  MCMV 

As  it  traverses  the  minefield  the  MCMV  is  at  risk  from  mines  which  may  be  actuated 
by  its  passage.  In  the  model  whenever  the  MCMV's  position  is  updated  a  check  is 
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made  to  see  whether  it  has  intercepted  the  actuation  width  of  any  live  mines.  If  it  has  a 
further  check  is  made  to  determine  whether  the  MCMV  is  damaged.  The  model  allows 
for  the  possibility  that  the  MCMV  can  actuate  and  detonate  mines  with  no  risk  to  itself. 

The  interaction  between  the  MCMV  and  a  mine  is  defined  by  the  parameters 
chahacteristic  actuation  width  A,  characteristic  actuation  probability  B,  dangerous 
front  F,  and  damage  probability  defined  in  NATO  documentation  [9].  The  worst 
case  scenario  is  assumed  with  all  mines  on  ship  count  1  with  zero  arming  delays 
poised  to  fire. 

2.4.4  Statistical  Analysis  of  Simulation  Results 

Simulation  models  can  compute  average  results  over  many  replications  of  a  particular 
scenario.  It  is  important  for  the  user  to  estimate  the  statistical  accuracy  of  these  results. 
This  is  achieved  in  the  present  model  by  using  running  variables  which  accumulate 
during  the  simulation.  For  example,  clearance  level  for  replication  i  is  determined 
from 


cli  =  dj/rii  (7) 

where  dj  is  the  number  of  mines  disposed  and  n/  the  number  of  mines  in  the  field  for 
replication  i.  The  mean  value  for  clearance  level  is  given  by: 

R  R 

CL  =  =  d^i  / (8) 

i=l  i=l 

where  daii  is  the  total  number  of  mines  disposed  and  tiaii  is  the  total  number  of  mines 
placed  in  the  field  over  all  R  replications.  TTie  standard  error  is  then  computed  as: 


SE  =  \IRx 


R 

cli"  +  RxCL^  -  2CLY,cI, 
1=1 


(9) 


that  is  the  standard  error  is  a/^R  where  a  is  the  standard  deviation  in  a  single 
measurement  [10].  Rather  than  storing  the  individual  cZj  values  two  running  variables 
l£ll  and  Iclj  ^  are  updated  for  each  replication  so  that  the  standard  error  can  be 
calculated  when  all  replications  are  complete.  Between  each  replication  the  numbers  of 
mines  and  non-mines  and  their  positions  are  varied,  the  outcomes  of  the  critical  events, 
and  the  delay  times  between  these  events, 

2.4.5  Output  from  the  Model 

The  output  from  the  model  has  also  been  considerably  expanded.  MOEs  such 
as  clearance  level  have  their  statistical  accuracies  included.  The  average  wait 
times  for  each  resource,  such  as  an  ROV  waiting  for  a  charged  battery  are  also 
included.  The  values  of  attributes  used  in  the  simulation  rim  are  also  printed. 
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times  for  each  resource,  such  as  an  ROV  waiting  for  a  charged  battery,  are  also 
included.  The  values  of  attributes  used  in  the  simulation  run  are  also  printed.  A 
listing  of  the  MOEs  output  is  given  in  Table  1.  These  are  grouped  into  performance, 
average  number  of  each  procedure,  and  average  times.  More  detail  is  given  in  section 
3.3. 

Table  1:  Output  Measures  of  Effectiveness 


General  Performance 

Average  Timings 

Fraction  of  Mines  Detected 

Total  Search  Time 

Fraction  of  Mines  Undetected 

Total  Classification  Time 

Fraction  of  Mines  Correctly  classified 

Total  Identification  Time 

Clearance  Level 

Total  Clearance  Time 

Clearance  Rate 

Total  Wait  Time 

Average  Procedure  Count 

Average  no.  of  Detections 

Average  no.  of  Classifications 

Average  no.  of  Identifications 

Average  no.  of  Missed  Mine-Like  Objects 
Average  no.  of  Disposals 

Graphical  output  is  achieved  by  writing  data  for  mine/non-mine  positions  and 
MCMV/ROV  positions  to  a  data  file.  This  file  can  be  accessed  from  an  external  Visual 
Basic  program  MH_GRAF.EXE  which  reads  this  file  and  then  does  a  plot  of  the  final 
replication  of  the  simulation. 


2.4.6  Sampling  from  Distributions 

In  Version  1  of  the  model,  NAG  and  intrinsic  VAX  functions  were  used  to  provide 
random  deviates.  This  has  been  replaced  by  using  the  random  number  generator  of 
Scholz  [11],  which  provides  a  set  of  independent  random  number  streams  which  are 
also  machine-independent. 

To  account  for  the  effect  of  navigational  error,  it  is  necessary  to  sample  from  a 
gaussian  distribution  with  a  given  mean  and  standard  deviation.  A  routine  was 
written  using  the  Box-Muller  algorithm  [12],  which  uses  the  Scholz  routine  to  provide 
a  source  of  uniformly  distributed  variates. 

To  select  numbers  of  mines  and  non-mines  from  their  respective  densities  it  is 
necessary  to  sample  from  Poisson  distributions  with  means  the  average  numbers  of 
mines  and  non-mines  in  the  field.  This  was  done  by  first  generating  and  storing 
vectors  of  Poisson  probabilities  with  these  means  and  then  using  the  acceptance- 
rejection  technique  to  select  a  random  integer  from  the  distribution.  The  Scholz 
routine  is  used  to  provide  a  source  of  variates. 
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Reaction  times  for  the  various  states  are  also  subject  to  random  variations.  In  die 
model  these  reaction  times  are  determined  by  sampling  from  a  gamma  distribution 
with  two  degrees  of  freedom  for  a  given  mean  reaction  time  value.  The  gamma 
distribution,  which  is  skewed  in  the  positive  time  direction,  is  commonly  used  in 
simulation  models  for  determining  these  delay  times  [13]. 


2.5  Model  Limitations 

The  MHUNT  model,  like  all  models,  is  an  abstraction  from  the  real  world.  It  was 
written  for  a  high  level  evaluation  of  minehunting  performance,  and  is  a  more 
simplified  model  than,  e.g.  the  UK's  MCS  model  [14].  The  detailed  specifications  and 
explanatory  text  given  in  this  Note  expose  the  assumptions  behind  the  model.  The 
specifications  were  scrutinised  and  agreed  by  the  Navy  sponsor  to  be  reasonable  for 
the  purposes  of  the  MHC  Effectiveness  Study.  The  main  simplifications  and 
approximations  made  by  the  model  are: 

•  The  minefield  is  a  two  dimensional,  rectangular  area  in  which  sets  of  identical 
mines  and  non-mines  are  located  at  random  points,  governed  by  their  respective 
area  densities. 

•  The  MCMV  is  a  point  which  moves  through  the  minefield  along  straight,  parallel 
tracks,  except  when  it  is  necessary  to  divert  from  the  track  to  approach  a  contact 
(mine  or  non-mine)  which  has  been  detected.  The  speed  of  the  MCMV  is  constant 
in  the  search  and  classification  phases  of  its  operations.  It  is  stationary  from  when 
an  ROV  is  deployed  to  when  the  ROV  is  recovered.  It  approaches  a  detected  contact 
along  the  radius,  and  returns  to  the  track  along  the  perpendicular. 

•  The  MCMV  navigation  and  track  keeping  error  is  modelled  by  adding  a  random 
number  from  a  distribution  with  zero  mean  and  given  variance  each  time  the 
MCMV  position  is  updated,  i.e.  at  each  discrete  event. 

•  The  minehunting  sonar  is  a  sector  shaped  area  pointing  parallel  to  the  track  m 
detection  mode,  and  a  circular  shape  in  classification  mode.  Detection  is 
determined  by  means  of  a  cumulative  probability  curve,  and  classification  by 
correct  classification  probabilities  for  mines  and  non-mines.  A  detection  probability 
reduction  factor  is  included  to  take  account  of  the  reduction  in  detection  probability 
in  the  wings  of  the  detection  envelope. 

•  Detection  and  classification  ranges  used  by  the  MHUNT  model  are  calculated  by  the 
MINERAY  model  [7]  for  a  given  set  of  target  and  envirorunental  conditions.  Thus 
the  approximations  made  by  the  MINERAY  model  also  apply  fo  the  MHUNT 
model.  These  include  an  isotropic  mine  target  strength,  average  weather  and  sea 
bottom  conditions  and  a  uniform  sound  velocity  profile. 

•  The  MCMV  only  deals  with  a  single  contact  at  a  time,  i.e.  contacts  detected  and 
classified  as  mines  are  disposed  of  by  an  MDC  placed  by  the  ROV  (if  identified  as  a 
mine),  and  then  the  next  contact  dealt  with.  A  more  realistic  model  would  allow,  in 
some  circumstances,  two  or  more  contacts  to  be  detected  at  the  same  time,  their 
positions  marked,  and  disposed  of  sequentially. 

•  The  ROV  is  a  point  which  always  moves  from  the  MCMV  directly  to  the  contact  at  a 
constant  speed.  Hydrodynamic  effects  and  sea  currents  are  not  modelled.  It  always 
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finds  the  contact,  and  identifies  it  with  a  constant  (within  a  simulation  run) 
probability  of  being  correct. 

•  Transit  to  and  from  the  minefield  in  accordance  with  the  MCMV  operating  cycle, 
and  operational  availability  constraints  due  to  equipment  unserviceability  and 
weather  are  not  currently  modelled  (although  the  parallel  process  structure  of  the 
model  would  facilitate  inclusion  of  these  factors). 

•  The  interaction  between  the  MCMV  and  a  mine  is  modelled  by  actuation  and 
damage  widths.  If  an  MCMV  comes  within  these  widths,  actuation  and  damage 
occurs  with  specified  probabilities.  These  parameters  are  an  approximation  to 
TMSS  actuation  probability  contour  results  [15],  although  the  error  in  doing  so  is 
probably  small. 

Whilst  it  can  be  argued  that  the  above  assumptions  place  limitations  on  the  accuracy  of 
the  results  produced  by  the  model,  it  must  be  stated  that  to  produce  valid  results  a 
model  needs  valid  input  data.  The  input  data  for  the  MHUNT  model,  described  in 
Section  3.2  below,  was  highly  variable  in  this  regard,  many  parameters  having  to  be 
estimated  and  some  having  uncertainties  of  several  hundred  percent.  Thus  it  is 
believed  that  the  model  is  an  appropriate  tool  for  comparative  operational 
effectiveness  studies  of  minehunting  systems,  but  must  be  used  judiciously. 


3.  Running  the  Model 

3.1  IBM  PC  Model  Operation 

The  model  is  run  by  entering  MHUNT  at  the  DOS  prompt  on  an  IBM  PC  or 
compatible.  The  model  employs  a  menu-driven  interface  with  options  selected  by 
entering  a  single  character.  The  user  is  presented  with  the  model's  title  screen 
containing  program  name,  author  information,  place  of  origin,  and  date  as  shown  in 
Figure  8. 


MINEHUNTING  SIMULATION  MODEL  -  MHUNT  *** 

***  SIMULATES  MCMV/ROV  CLEARANCE  OPERATION  *** 

WRITTEN  BY  :  PETER  RYAN  &  RICHARD  WATSON  -  1994 
MARITIME  OPERATIONS  DIVISION 
MATERIALS  RESEARCH  LABORATORY 
DSTO-MELBOURNE 
DATE :  18/  7/1994 

TYPE  RETURN  TO  START  SIMULATION  » 


Figure  8:  Title  screen  for  MHUNT  model 


17 


DSTO-TN-0003 


On  entering  a  return  character  the  next  screen,  the  master  menu,  is  obtained  as 
shown  in  Figure  9. 


MINEHUNTING  EVALUATION  PROGRAM 

DEFINE  SCENARIO 

(1) 

SOLVE  MCM  PROBLEM 

(2) 

DO  GRAPHICS 

(3) 

EXIT 

(E) 

ENTER  OPTION  » 

Figure  9:  Master  Control  menu  for  MHUNT  model 


If  a  is  entered  the  Define  Scenario  Menu  shown  as  Figure  10. 


define  SCENARIO  MENU 

READ  DATA  FROM  FILE 

(1) 

SET  PARAMETERS  MANUALLY 

(2) 

PRINT  PARAMETERS 

(3) 

EXIT 

(E) 

ENTER  OPTION  » 

Figure  10:  Define  Scenario  menu  for  MHUNT 


If  a  '1'  is  entered  here  the  model  prompts  for  a  file  name.  This  file  contains  all  the 
data  required  to  run  the  model.  If  a  '2'  is  entered  the  manual  input  option  is  selected 
and  the  screen  shown  as  Figure  11  is  produced. 
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manual  input  menu  **** 

SET  UP  MINEFIELD 

(1) 

SET  UP  MINEHUNTER 

(2) 

SET  UP  ROV 

(3) 

SET  UP  BATTERY  CHARGER 

(4) 

SET  UP  DISPOSAL  CHARGES 

(5) 

SET  UP  SONAR  INTERACTION 

(6) 

SET  UP  DAMAGE  INTERACTION 

(7) 

EXIT 

(E) 

ENTER  OPTION  » 

Figure  1 1 :  Manual  Input  Menu  for  MHUNT 


After  the  input  has  been  specified,  either  by  reading  data  from  a  file  or  by  entering  it 
manually,  the  parameters  can  be  checked  by  returning  to  the  'Define  Scenario'  menu 
and  entering  the  character  '3'  (Figure  10).  This  produces  the  menu  shown  as  Figure  12. 


PRINT  PARAMETER  MENU 

MINEFIELD  PARAMETERS 

(1) 

MINEHUNTER  PARAMETERS 

(2) 

ROV  PARAMETERS 

(3) 

BATTERY  CHARGER  PARAMETERS 

(4) 

DISPOSAL  CHARGE  PARAMETERS 

(5) 

SONAR  INTERACTION  PARAMETERS 

(6) 

MCMV  SAFETY  PARAMETERS 

(7) 

EXIT 

(E) 

ENTER  OPTION  » 

Figure  12:  Print  parameter  menu 


Once  the  user  is  satisfied  that  the  scenario  is  defined  properly,  he  can  proceed  to  run 
the  simulation  by  entering  the  character  '2'  from  the  master  menu  (Figure  9)  to  solve 
the  simulation  problem.  Tliis  produces  the  simulation  control  menu  in  Figure  13. 
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SIMULATION  CONTROL  MENU 

Define  MCM  Tactics  (NOT  SET) 

(1) 

Number  of  MC  Replications  [  10] 

(2) 

Random  Number  Seed  [1891356973] 

(3) 

EXIT 

(E) 

ENTER  option  » 

Figure  13:  Simulation  control  menu 


Figure  14  shows  the  screen  produced  during  the  execution  of  the  MHUNT  model. 
For  each  10%  of  replications  completed,  the  raw  simulation  results,  such  as  numbers  of 
mines  detected  and  disposed,  are  printed  to  the  screen.  This  can  be  used  for 
debugging  purposes  and  to  provide  an  indication  of  completion  time  for  the 
simulation  run. 


20%  completed  (  20)  of  100  replications 

MINES  :  Total  Mines  in  Field 

200 

Detected  Mines 

= 

172 

Undetected  Mines 

= 

28 

Mines  classified  as  Mines 

= 

139 

Mines  classified  as  Non-Mines 

= 

33 

Mines  identified  as  Mines 

= 

139 

Mines  disposed  by  ROV 

= 

139 

Mines  disposed  by  MCMV 

= 

0 

Mines  disposed 

139 

NON-MINES:  Total  Non-Mines 

= 

209 

Detected  Non-Mines 

z= 

176 

Undetected  Non-Mines 

= 

33 

Non-mines  classified  as  Non-Mines 

= 

163 

Non-mines  classified  as  Mines 

= 

13 

Non-mines  identified  as  Mines 

= 

0 

Non-mines  disposed  by  ROV 

= 

0 

MCMVS:  MCMV  Casualties 

= 

0 

Figure  14:  Screen  produced  during  execution  of  MHUNT 
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3.2  Input  Data 

The  input  data  for  the  model  is  shown  in  Figure  15.  It  is  divided  into  7  parts  -  the 
minefield  parameters,  the  MCMV  parameters,  ROV  parameters,  the  battery  charger 
parameters,  the  mine  disposal  charge  parameters,  the  sonar/ mine  interaction 
parameters,  and  the  MCMV/mine  interaction  parameters  for  mine  actuation  and 
damage. 


GENERIC  DATA  USED  FOR  TESTING  MODEL 

******  MINEFIELD  PARAMETERS  ****** 

1891356973 

!  Random  no.  seed 

397204094 

!  Multiplier 

4 

!  No.  of  streams 

99999 

!  Offsets  l..nstream 

999999 

9999999 

99999999 

1000. 

!  Minefield  Width  (m) 

10000. 

!  Minefield  Length  (m) 

20. 

!  Minefield  Depth  (m) 

DISCRETE 

!  Seeding  option  for  Mines 

10 

!  No.  of  mines  in  field 

.TRUE. 

!  Mines  placed  at  random  positions 

DENSITY 

!  Seeding  option  for  Non-Mines 

1.0 

!  Density  of  Non-Mines  (per  sq  km) 

******  MCMV  PARAMETERS  ****** 

5.0 

!  Navigational  error  (m) 

4.0 

!  MCMV  Speed  (detection  mode)  in  knots 

2.0 

!  MCMV  Speed  (classification  mode)  in  knots 

50.0 

!  Increment  for  MCMV  movement  along  track 

5.0, 2.0,  8.0 

!  Turn  time  (min)  +  Min/Max 

******  ROV  PARAMETERS  ****** 

2 

!  Number  of  ROVs 

B 

!  ROV  Type  (B  or  C) 

2.0 

!  Speed  in  knots 

20.0, 10.0,  30.0 

!  Time  to  deploy  ROV  (min)  +  Min/Max 

10.0, 5.0, 15.0 

!  Relocation  time  (min)  +  Min/Max 

10.0, 5.0, 15.0 

!  Identification  time  (min)  +  Min/Max 

10.0, 5.0, 15.0 

!  Charge  lay  time  (min)  +  Min/Max 

20.0, 10.0,  30.0 

!  Recovery  time  (min)  +  Min/Max 

5.0 

!  Turnaround  time 

10.0 

!  Decision  time 
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***’^**  BATTERY  CHARGER  PARAMETERS  ’^■'**** 

2 

!  No.  of  battery  chargers 

3 

!  No.  of  batteries 

300 

!  Battery  charge  time  (mins) 

120 

!  Battery  life  (mins) 

******  disposal  charge  parameters  ****** 

30 

!  No.  of  disposal  charges 

30 

!  Arming  delay  (mins) 

10 

!  Firing  delay  (mins) 

******  SONAR  INTERACTION  PARAMETERS  ****** 

■TRUE. 

!  Sonar  data  read  from  file 

.FALSE. 

!  Rectangular  parameters  not  used 

sonar.dat 

!  Sonar  detection  probability  data  file  name 

50.0 

!  Min.  detection  range  (m) 

500.0 

!  Max.  detection  range  (m) 

400.0 

!  Range  for  90%  detection  probability 

90.0 

!  Sector  angle  (deg.) 

20.0 

!  Sector  edge  reduction  factor  (%) 

1.0 

!  Max.  detection  probability 

300. 

!  Classification  range  (m) 

300. 

!  Classification  width  (m) 

0.80 

!  Classification  probability  for  mine 

0.90 

!  Classification  probability  for  non-mine 

15.0, 10.0, 20.0 

!  Mean  classification  time  +  Min/Max  (min) 

1.0 

!  Relocation  probability 

1.0 

!  Identification  probability 

******  mcmv/mine  interaction  parameters  ****** 

50.0 

!  Actuation  width,  A  (m) 

0.1 

!  Actuation  prob.  (B) 

50.0 

!  Damage  Width,  F  (m) 

0.5 

!  Damage  Probability  (Bd)  if  actuation  occurred 

100.0 

!  Hover  Radius  (m) 

200.0 

!  Safe  Fire  Position  (m) 

Figure  15:  Input  parameters  and  typical  values 


3.2.1  Minefield  Parameters 

The  minefield  input  data  include  random  number  seeding  parameters,  minefield 
dimensions,  and  seeding  options  for  mines  and  non-mines.  Note  that  for  this 
minefield  there  are  10  mines  placed  randomly  for  each  replication,  whereas  the 
number  of  non-mines  is  determined  by  sampling  a  Poisson  distribution  with  mean  10 
non-mines  (non-mine  density  of  1  per  sq  km  x  10  sq  km). 
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3.2.2  MCMV  Parameters 

The  MCMV  input  data  include  speeds  for  detection  and  classification  modes  of 
operation,  navigational  error  parameters  and  also  turn  time.  The  increment  is  used  for 
selecting  detection  ranges. 


3.2.3  ROV  Parameters 

The  ROV  input  data  mainly  consists  of  the  times  required  to  perform  each  of  its 
mission  steps,  such  as  deployment  and  mine  identification.  Note  that  the  ROV  type 
specified  here  is  battery-powered  designated  by  'B'.  The  alternative  type  of  ROV 
permitted  by  the  model  is  cable-powered  designated  by  'C'. 

3.2.4  Battery  Charger  Parameters 

The  battery  charger  parameters  include  the  number  of  chargers,  total  number  of 
batteries,  and  charge  time  and  battery  life  parameters 


3.2.5  Disposal  Charge  Parameters 

The  disposal  charge  parameters  comprise  the  number  of  disposal  charges,  the  arming 
delay  applied  to  each  charge  when  laid,  and  the  firing  delay.  This  firing  delay  is  the 
time  delay  applied  to  the  firing  after  the  MCMV  has  reached  the  safe  distance. 


3.2.6  Sonar  Interaction  Parameters 

Here  sonar  cumulative  probabilities  as  a  function  of  range  are  read  from  an  external 
data  file.  The  remaining  parameters  specify  the  limits  of  contact  detection, 
classification  parameters,  and  the  relocation  and  identification  probabilities. 


3.2.7  MCMV/Mine  Interaction  Parameters 

These  parameters  are  used  to  determine  whether  (a)  a  mine  is  accidentally  actuated  if 
the  MCMV  passes  close  by  and  (b)  if  the  MCMV  is  damaged  by  such  a  mine  actuation. 
The  safe  fire  position  defines  the  distance  the  MCMV  has  to  be  placed  from  the  mine 
before  the  disposal  charge  is  fired  remotely. 
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3.3  Output  Results 

The  model  output  can  be  written  either  to  the  DOS  screen  or  to  a  file.  In  either  case 
there  are  4  pages  of  output  data  contained  below  in  Figure  16.  This  output  was 
produced  using  the  above  input  data  set  for  500  replications  of  the  model. 


MEASURES  OF  MINEHUNTING  EFFECTIVENESS 

Fraction  Detected 

77.20%(+/-  0.63%) 

Fraction  Undetected 

= 

22.80  %(+/-  0.63%) 

Mines  Classified  Correctly 

= 

62.22  %(+/-  0.73%) 

Clearance  Level  (TOTAL) 

= 

62.52  %(+/-  0.71%) 

Clearance  Level  (SAFE) 

= 

62.88  %(+/-  0.77%) 

Countermeasures  Risk 

= 

0.22%  (+/-  0.25%) 

Expected  Casualties 

= 

0.014  (+/-  0.01) 

Avge  no.  detections 

15.34  (Mines:  7.72  Non-Mines:  7.62) 

Avge  no.  mine  classifications 

= 

6.97  (Mines:  6.22  Non-Mines:  0.75) 

Avge  no.  mine  identificatioias 

= 

6.22  (Mines:  6.22  Non-Mines:  0.00) 

Avge  no.  missed  miles 

= 

4.45  (Mines:  2.28  Non-Mines:  2.17) 

Avge  no.  mine  disposals 

= 

6.25(ByROV;  6.22ByMCMV:  0.03) 

Avge  no.  mine  disposals  (SAFE) 

= 

6.20 

Avge  no.  non_mine  disposals 

= 

0.00 

Avge  no.  non_mine  disposals  (SAFE) 

= 

0.00 

Figure  16(a):  Page  1  of  output-  mean  measures  of  effectiveness  for  minehunting 


MEASURES  OF  MINEHUNTING  EFFECTIVENESS  -  TIMES 

Search  Time  = 

2  hrs  26  mins  +/-  .5%  ( 12.0%  of  total) 

Classification  Time  = 

4  hrs  15  mins  +/-  1.1%  ( 20.9%  of  total) 

Identification  Time  = 

3  hrs  44  mins  +/-  1.3%  ( 18.3%  of  total) 

Disposal  Time  = 

8  hrs  51  mins  +/-  1.2%  ( 43.5%  of  total) 

Total  Clearance  Time  = 

20  hrs  20  mins  +/-  1.0%  ( +  MCMV  Wait  Time) 

Wait  time  = 

1  hrs  5  mins 

Avge  time  BCl  waiting  for  a  battery  =  119.14  mins 

Avge  time  BC2  waiting  for  a  battery  =  216.24  mins 

Avge  time  spare  ROV  waiting  for 

a  battery  =  96.13  mms 

Avge  time  next  ROV  waiting  for  a 

battery  =  68.11  mins 

Avge  time  MCMV  waiting  for  ROV  =  34.53  mins 

Clearance  Rate 

=  0.492  sq  km/hr 

Average  Advance  Speed 

=  0.141  knots 

Total  Distance  (Lap  Tracks) 

=  20000.0  m 

Total  Distance  Travelled 

=  23735.9  m 

Figure  16(b):  Page  2  of  output  -  times  for  processes 
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SUMMARY  OF  SIMULATION  RUN 

Number  of  Tracks 

2 

Average  No  of  Runs/Track 

= 

1.00 

Minefield  Width  = 

1000.0  m 

Minefield  Length  = 

10000.0  m 

Track  Spacing 

= 

500.0  m 

Average  Mine  Density 

= 

1.000  per  sq  km 

Average  Non-Mine  Density 

= 

.979  per  sq  km 

Number  of  Replications 

= 

500 

Himting  Tactic 

= 

MINIMUM  EFFORT 

Extra  Track  at  Edge 

= 

NO 

Elapsed  CPU  Time 

= 

141.21  secs 

Figure  16(c):  Page  3  of  output  -  summary  of  simulation 

VALUES  OF  ATTRIBUTES  USED  IN  THE  RUN 

No  of  battery  chargers  =  2  No  of  batteries  = 

3 

NoofROVs  =2  ROVtype 

=  B 

90  %  Detection  Range  =  400.0  m 

Detection  Width  =  565.7  m 

Max  Detection  Range  =  625.0  m 

Min  Detection  range  =  25.0  m 

Classification  Range  =  300.0  m 

TIMES  IN  MINUTES 

MEAN 

MIN 

MAX 

MCMV  Transit  Time  to  Op  Area 

240.0 

120.0 

360.0 

Contact  Classification  Time 

15.0 

10.0 

20.0 

Contact  Identification  Time 

10.0 

5.0 

15.0 

MDC  Laying  Time 

10.0 

7.5 

15.0 

ROV  Recovery  Time 

20.0 

10.0 

30.0 

MDC  Arming  Time 

30.0 

30.0 

30.0 

MDC  Firing  Time 

10.0 

10.0 

10.0 

Battery  Charge  Time 

300.0 

225.0 

450.0 

Spare  ROV  Turnaround  Time 

5.0 

3.8 

7.5 

ROV  Decision  Time 

10.0 

5.0 

15.0 

Next  ROV  Turnaround  Time 

5.0 

3.8 

7.5 

***  RESULTS  FILE  =  mhunt.out 

Figure  16(d):  Page  4  of  output  -  values  of  attributes  used  in  simulation 


3.3.1  Page  1:  Mean  Measures  of  Effectiveness 

This  page  contains  the  averaged  MOEs  for  fraction  of  mines  detected,  cleared  etc. 
together  with  the  average  number  of  times  each  process  such  as  a  mine  classification 
was  carried  out.  Note  that  the  clearance  level  designated  TOTAL  denotes  the  clearance 
level  for  all  replication,  whereas  that  designated  SAFE  denotes  the  clearance  level  for 
those  replications  where  the  MCMV  remained  undamaged. 
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3.3.2  Page  2:  Mean  Times  for  Minehunting  Performance 

This  page  contains  the  time  measures  of  effectiveness  (in  hours  and  minutes)  such  as 
average  total  clearance  time.  The  average  wait  times  for  each  of  the  processes  in 
minutes  are  also  included.  These  results  can  indicate  whether  the  clearance  operation 
is  adversely  affected  by  time  delays. 

The  clearance  rate  is  calculated  by  dividing  the  area  cleared  by  the  total  clearance 
time.  The  average  speed  of  advance  is  computed  from  the  total  distance  travelled 
across  the  minefield  (20000  m  for  one  run  along  each  of  two  tracks).  The  total  distance 
travelled  by  the  MCMV  is  to  be  contrasted  with  the  total  lap  track  distance  and 
provides  an  indication  of  the  off-track  excursions  made  by  the  MCMV  while 
classifying  and  disposing  of  mines. 


3.3.3  Page  3:  Summary  of  Simulation 

This  page  provides  a  summary  of  the  simulation  run  including  tactics  data,  minefield 
data,  and  elapsed  CPU  time  used  by  the  computer.  Here  a  tactic  of  one  run  on  each  of 
two  500  m  wide  tracks  is  used,  determined  from  the  minimum  effort  tactic.  The  option 
of  including  an  extra  track  close  to  the  edge  of  the  channel  is  disabled. 


3.3.4  Page  4:  Values  of  Attributes 

This  page  includes  the  attribute  values  used  in  the  simulation,  such  as  the  number  of 
battery  chargers  and  total  number  of  batteries.  The  ranges  of  possible  values  from 
minimum  to  maximum  for  each  of  the  reaction  times  are  also  included.  The  model 
samples  delay  times  from  within  these  limits. 


3.4  Event  State  Trace 

The  event-state  trace  is  an  optional  output  from  single  replication  runs  of  the 
simulation.  It  provides  the  time  each  event  occurs,  the  event  name,  and  the  value  of 
each  event  pointer  element.  All  simultaneous  events  are  listed,  followed  by  a  state 
trace,  with  the  system  variables  also  listed  after  the  state  trace.  The  event-state  trace  is 
very  useful  for  verifying  that  the  program  operates  as  specified  by  the  directed  graph, 
and  for  debugging.  Further,  once  the  model  has  been  verified  and  validated,  the 
program  can  be  rvm  in  event-state  trace  mode  to  better  understand  the  actual  system 
operation. 

Complete  details  of  the  event  state  trace  are  provided  in  Annex  D.l 
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3.5  Graphical  Output 

Graphical  output  can  be  obtained  by  writing  an  ASCII  graphics  external  file.  This  file 
can  then  be  accessed  by  an  external  Visual  Basic  code  and  a  reconstruction  of  the  last 
replication  performed  can  be  displayed  on  the  screen. 

Details  of  the  graphics  file  format  are  provided  in  Annex  D.2.  A  sample  plot  is 
shown  as  Figure  17  with  the  key  included. 

The  MHUNT  model  has  been  adapted  to  work  under  a  Visual  Basic  interface.  Visual 
Basic  uses  Microsoft  Fortran  Dynamic  Link  Libraries  (DLLs)  to  replace  the  Fortran 
DOS  program. 


4.  Discussion  and  Conclusion 

Modelling  and  simulation  are  powerful  tools  with  which  to  study  MCM.  Simulation 
models  have  been  developed  both  for  the  target/ mine  encounter  and  also  for  minefield 
clearance  operations.  Since  the  simulation  is  flexible,  these  models  can  be  changed  to 
reflect  improved  knowledge  and  it  provides  a  low  cost  alternative  to  carrying  out 
costly  trials. 

A  discrete-event  simulation  model  has  been  described  for  naval  minehunting.  The 
model  functions  by  imitating  the  real  world  minehunting  process  in  a  simplified 
fashion.  The  minehunting  procedure  is  reduced  to  a  set  of  connected,  discrete  events 
and  the  outcome  of  each  of  these  is  determined  by  random  sampling.  Measures  of 
effectiveness,  such  as  clearance  and  risk,  can  be  determined  by  executing  many 
replications  of  a  particular  scenario. 

The  model  was  specified  using  a  modified  state  transition  diagram  methodology  and 
developed  with  the  assistance  of  third-party  event-management  software.  The  model 
incorporates  multiple  parallel  processes  for  the  MCMV,  MDC,  battery  charger,  spare 
ROV  and  next  ROV.  This  software  enables  the  parallel  processes  to  be  modelled  using 
linked  lists  of  future  events  and  wait  states. 
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Figure  17:  Graphical  output  and  description  key 
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Annex  A:  Clymer's  Methodology 


The  MHUNT  model  was  specified  by  Clymer's  directed  graph  notation,  which  is  a 
form  of  state  transition  diagram  [Al].  It  incorporates  Clymer's  event  management 
software  to  control  its  dynamic  behaviour.  This  notation  and  software  are  described  in 
this  Annex. 


A.1  Clymer's  Directed  Graph  Notation 

A  discrete  event  simulation  model  may  be  regarded  as  a  finite  state  machine,  which  is 
a  hypothetical  machine  which  can  only  be  in  one  of  a  given  number  of  states  at  a  time. 
In  response  to  an  input,  the  machine  may  generate  an  output  and/or  change  state. 
Both  file  output  and  the  new  state  are  purely  functions  of  the  current  state  and  the 
input.  A  state  transition  diagram  (STD)  is  one  means  of  defining  a  finite  state  machine. 
One  form  of  STD,  the  activity  cycle  diagram,  has  been  used  to  specify  simulation 
models  for  many  years  [A2].  It  is  noteworthy  that  in  recent  years  the  STD  has  taken  on 
a  new  importance  as  a  tool  for  specifying  the  external  behaviour  of  complex  software 
systems  such  as  distributed  and  real-time  systems  [A3]  and  object-oriented  systems 
[A4].  Significant  extensions  to  the  range  of  concepts  describable  by  the  STD  have  been 
made  by  [A5],  mainly  for  specifying  complex  real-time  software  systems  but  also 
applicable  to  simulation  modelling. 

Clymer's  directed  graph  notation  is  a  form  of  STD  which  represents  the  operational 
behaviour  of  a  system  containing  parallel  (concurrent)  processes.  Each  process  is  a 
subordinate  finite  state  machine,  and  the  state  of  the  total  system  is  a  combination  of 
the  states  of  each  subordinate  machine.  Harel  ([A5])  uses  the  term  orthogonal  to 
describe  this  type  of  decomposition.  If  a  system  described  using  Clymer's  notation 
was  described  by  a  conventional  STD,  which  does  not  use  orthogonal  decomposition, 
the  number  of  states  would  be  greater  and  the  diagram  would  be  much  harder  to 
understand. 

A  parallel  process  in  Clymer's  notation  is  a  sequence  of  states  and  events,  events 
marking  points  in  time  when  a  change  of  state  occurs.  (In  Harel's  notation,  the  term 
transition  denotes  a  change  of  state,  and  the  term  event  generally  means  a  message  sent 
from  one  process  to  another,  which  may  or  may  not  cause  a  change  of  state).  Cl)aner 
distinguishes  four  kinds  of  states,  although  circles  are  used  for  all  of  them  (unlike 
activity  cycle  diagrams).  They  may  be  distinguished  as  follows,  however: 


Wait  Semicontinuous  Idle 


Reaction  Time 

Figure  A.1:  States  used  by  Clymer 
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Reaction-time  states  represent  the  length  of  time  a  resource  is  performing  a  particular 
function.  In  simulation  models,  reaction  times  are  often  computed  by  a  random- 
variable  generator.  In  a  queueing  application,  for  example,  a  server  serving  a  customer 
would  be  in  a  reaction-time  state.  (They  are  equivalent  to  active  states  in  activity  cycle 
diagrams). 

Wait  states  represent  the  time  a  process  waits  for  a  logical  condition  to  be  satisfied, 
and  the  process  will  remain  in  this  state  vmtil  the  condition  is  satisfied.  Harel  (ref. 
[A5])  terms  this  a  guard  condition,  which  can  also  determine  the  state  to  which  a 
reaction-time  state  transitions  after  the  reaction-time.  In  a  queueing  application,  for 
example,  a  customer  waiting  in  a  queue  for  service  would  be  in  a  wait  state.  (They  are 
equivalent  to  dead  states  in  activity  cycle  diagrams).  The  logic  that  activates  the  event 
may  be  in  the  event  itself  or  elsewhere.  In  the  latter  case  the  state  is  said  to  be 
passivated,  and  the  process  will  remain  in  it  xmtil  an  appropriate  message  from  another 
process  is  received. 

A  semicontinuous  state  approximates  the  continuous  behaviour  of  a  detailed  model  of 
system  operation.  State  variables  associated  with  this  kind  of  state  are  updated 
frequently  to  model  a  process  that  varies  continuously.  In  the  MHUNT  specification, 
semicontinuous  states  are  not  used. 

An  idle  state  is  a  type  of  wait  state  which  represents  a  period  of  time  a  process  is 
waiting  for  one  or  more  other  processes  to  be  completed  before  an  assemble  event  can 
occur. 

Clymer's  notation  for  a  simple  parallel  process  is  thus  as  follows: 


Initial 

State 


-<1>- 

Event 1 
Begin  Carry  out 
Operation  Operation 


-<2> - 

Event  2 

Finish 

Operation 


Final 

State 


Figure  A.2:  Clymer  notation  for  parallel  process 


Clymer  also  introduces  a  special  notation  for  the  direct  execution  of  events,  as 
follows: 
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Figure  A.3:  Clymer  notation  for  direct  execution  of  events 

The  direct  execution  of  events  corresponds  to  a  message  from  another  process  which 
causes  a  transition  from  a  wait  state  irrespective  of  whether  the  guard  condition  logic 
is  satisfied,  or  a  premature  (i.e.  before  the  reaction  time  is  up)  transition  from  a  reaction 
time  state.  The  diagram  above  shows  a  transition  (Event  1)  from  a  wait  state  W1  which 
occurs  either  after  a  guard  condition  is  satisfied  (Entry  1)  or  after  a  message  is  received 
(Entry  2).  The  action  following  the  transition  (two  alternative  actions  are  shown  in  the 
diagram,  but  there  may  be  any  number)  may  be  determined  by  the  guard  condition  or 
the  message  parameters. 

In  Clymer's  notation,  particular  kinds  of  events  are  associated  with  the  splitting  of  a 
process  into  two  or  more  parallel  processes  or  the  synchronisation  of  two  or  more 
parallel  processes  into  one.  These  are  termed  split  events  and  assemble  events, 
respectively,  and  their  notation  is  shown  below  as  Figure  A.4: 


Figure  A.4:  Split  and  assemble  events 
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A.2  Clymer's  Event  Management  Executive  Software 

The  event  management  executive  software  provided  by  Clymer  is  stated  (pg  13  of  ref. 
[Al] )  to  use  a  combination  of  event-scheduling  and  modified  activity  scanning.  These 
methods  are  described  by  Pidd  ([A2]).  Clymer's  method  actually  bears  considerable 
resemblance  to  Pidd's  so-called  three  phase  method.  A  flow  chart  of  Clymer  s  MAIN 
simulation  routine  is  shown  below. 


Figure  A.5:  Flow  chart  of  event  management  software  from  Clymer  (ref.  [Al]). 

Clymer's  event  management  software  has  two  linked  lists  of  events:  the  future  events 
list  and  the  wait  list.  At  each  stage  of  the  simulation  cycle,  all  event  subroutines 
scheduled  to  occur  at  the  current  simulated  time  are  executed.  Then  each  event  on  the 
wait  list  is  tested  to  see  if  its  occurrence  logic  is  now  satisfied.  Occurrence  of  wait 
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events  is  tested  within  their  particular  event  routine.  Note  that  an  event  can  be 
scheduled  to  occur  immediately  after  another  event,  by  the  first  event  putting  it  on  the 
future  events  list  with  no  time  delay.  In  the  MHUNT  application,  event  22  in  the  Next 
ROV  Process  (decide  which  ROV  to  use  next)  directly  executes  event  19  in  the  Spare 
ROV  Process  in  this  way. 
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Annex  B:  Module  Descriptions  of  MHUNT  Model 


B.l  Overview  of  model 

The  MHUNT  program  consists  of  a  set  of  10  modules  described  briefly  below: 


MHimt 

Contains  input  routines 

MH_Clym 

Event-management  routines  from  Clymer 

MH_Event 

Contains  event  scheduling  for  each  parallel  process 

MH_Solve 

Event  routines 

MH_Res 

Converts  the  raw  data  into  measures  of  effectiveness  (nos.  of 
mines  disposed  is  converted  to  clearance  level,  for  example). 

PC_Graph 

Writes  ASCII  file  for  graphics 

MH_Sonar 

Sonar  detection  routines 

MH_Rand 

Random  number  generator  routines 

MH_Aux 

Auxiliary  routines 

MH_PC 

Routines  to  emulate  VAX  FORTRAN  intrinsic  routines 

Short  descriptions  of  each  routine  in  these  modules  are  provided  below.  These  are 
Fortran  subroutines  unless  indicated  otherwise. 


B.2  Module:  MHunt 

B.2.1  Define  Scenario 

Displays  menu  listing  selections,  reads  option  chosen,  then  acts  upon  choice. 


B.2.2  Get  Manual  Input 

Routine  to  read  in  input  data  to  define  the  scenario  manually.  This  routine  calls 
routines  B.2.4-B.2.10  below. 


B.2.3  Set  Defaults 

Sets  default  values  for  flags  and  numeric  constants,  initialises  the  random  number 
streams,  and  sets  string  constants  for  file  names. 
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B.2.4  Set  Up  Minefield 

Sets  the  minefield  dimensions,  minefield  seeding  type,  numbers /densities  of  mines 
and  non-mines. 

B.2.5  Set  Up  Hunter 

Sets  the  himter  variables  such  as  speed,  navigation  error  etc. 

B.2.6  Set  Up  ROV 

Sets  the  ROV  variables  such  as  speed,  times  for  deployment  and  recovery  etc. 

B.2.7  Set  Up  Bate 

Sets  the  battery  charger  variables  such  as  number  of  chargers,  time  to  charge  etc. 

B.2.8  SetUpMDC 

Sets  the  number  of  mine  disposal  charges  and  arming  delay. 

/ 

B.2.9  Set  Up  Sonar  Interaction 

Reads  in  the  file  containing  sonar/ mine  interaction  parameters. 

B.2.10  Set  Up  Damage  Interaction 

Sets  the  damage  interaction  parameters  for  the  MCMV. 

B.2.11  Get  Information  From  File 

Sets  the  scenario  by  reading  the  parameters  from  an  external  input  ASCII  data  file.  This 
is  an  alternative  to  the  manual  input. 

B.2.12  Print  Parameters 

Displays  print-menu,  reads  choice,  then  acts  upon  choice  which  calls  subroutines  to 
print  the  relevant  parameter  values.  Calls  the  following  two  routines. 
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B.2.13.Print  Rectangular  Parameters 

Prints  parameters  for  sonar/mine  interaction  if  the  'rectangular'  option  for  sonar 
performance  has  been  specified. 

B.2.14.  Print  Sonar  Parameters 

Prints  parameters  for  sonar/mine  interaction  if  the  sonar  option  has  been  set.  This 
reads  a  file  containing  detection  probabilities  as  a  function  of  range  from  the  MCMV . 

B.2,15.  Read  Sonar  Probs 

Reads  file  of  preset  name  for  setting  sonar  parameters. 

B.2.16.  Reset_Times 
Resets  time  parameters. 

B.3  Module:  MH  Clym 
B.3.1  MHimt  Clymer 
Controlling  routine  for  simulation. 

B.3.2  Print  Q 

Prints  the  wait  list  and  event  queues. 

B.3.3InitlQ 

Initialises  the  linked  lists  for  each  process'  event  queues. 

B.3.4  Remove 

Removes  events  from  queues 
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B.3.5  RMVWTQ 
Removes  events  from  wait  list. 

B.3.6  FileWT 

Schedules  wait  state  for  a  given  process. 

B.3.7FileVT 

Schedules  event  for  a  given  process 
B.3.8  UnFile 

Removes  specified  elements  from  all  linked  lists. 

B.3.9  NxtEvt  (Function) 

Determines  the  next  event  to  occur. 

B.4  Module:  MH_Event 
B.4.1  Start  MCM  Op 

Starts  the  MCM  operation:  displays  selective  information,  sets  parameters,  then  calls 
other  routines. 

The  following  5  routines  represent  the  parallel  processes:  MCMV,  Mine  Disposal 
Charge,  Battery  Charger,  Spare  ROV,  Next  ROV. 

B.4.2  MCMSim 

Processes  the  determined  event  for  the  MCMV 

B.4.3  MDCSim 

Processes  the  determined  event  for  the  MDC. 
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BAA  BATSim 

Processes  the  determined  event  for  the  battery  charger. 

B.4.5  SPRSim 

Processes  the  determined  event  for  the  Spare  ROV. 

B.4.6  NERSim 

Processes  the  determined  event  for  the  Next  ROV. 

B.4.7  Events 

Calls  particular  process  subroutine. 

B.4.8  DatCol 

Updates  data  collection  counters  for  the  time  between  the  last  and  current  events  of  the 
operational  sequence. 

B.4.9  ETrace 

Prints  the  descriptor  for  the  given  event. 

B.4.10  Readinput 

Sets  up  and  displays  a  menu,  reads  and  acts  upon  choice  then,  possibly,  changes  one  or 
more  sets  of  parameters. 

B.4.11  RWOutput 

Prints  report 

B.4.12  STrace 

Prints  selective  trace  information,  possibly  to  a  file. 
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B.4.13  StrCol 

Collects  run  statistics  at  the  end  of  each  operational  sequence. 

B.5  Module:  MH_Solve 
B.5.1  Define  Simulation 

Presents  menu  and  acts  upon  the  choice:  sets  tactics,  no.  of  replications,  random  no. 
seed. 

B.5.2  Define  Tactics 

Presents  menu  and  acts  upon  the  choice. 

B.5.3  Next  Encounter  (Function) 

Fimction  which  returns  the  next  mine  encountered  in  the  track. 

B.5.4  Calculate  Running  Totals 

Updates  the  mxmbers  of  mines/non-mines  detected,  classified,  disposed  etc.  and  other 
statistical  variables. 

B.5.5  Check  Detection 

Checks  whether  the  given  object  is  detected. 

B.5.6  Detect  Mile 

Samples  distribution  to  determine  if  a  given  object  is  detected. 

B.5.7  Move  MCMV  To  Classification 
Moves  the  MCMV  to  the  classification  distance. 

B.5.8  Check  Classification 

Checks  whether  the  contact  is  classified  by  sampling  from  a  uniform  distribution. 
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B.5.9  Move  MCMV  To  Hover 
Moves  the  MCMV  to  the  hover  position. 

B.5.10  Launch  ROV 

Launches  the  ROV  from  the  MCMV. 

B.5.11  Move  ROV  To  Contact 
Moves  the  ROV  to  the  contact  location. 

B.5.12  Check  Identification 
Checks  whether  the  contact  is  identified. 

B.5.13  Move  MCMV  To  Safety- 

Moves  the  MCMV  to  a  safe  position  after  the  ROV  has  been  recovered. 

B.5.14  Return  MCMV  To  Track 

Returns  the  MCMV  to  its  intended  track  after  completing  the  disposal  operation. 

B.5.15  Move  MCMV  To  End  Of  Track 

Moves  the  MCMV  to  the  end  of  the  track  because  there  are  no  more  mine-like  objects 
left  in  the  track. 

B.5.16  Check  Disposal 

Checks  whether  the  mine  has  been  disposed. 

B.5.17  Mile  In  Detection  Sector  (Function) 

Function  returning  true  if  a  given  contact  is  within  the  sonar's  detection  sector. 
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B.5.18  Mile  In  Classification  Sector  (Function) 

Function  returning  true  if  a  given  contact  is  within  the  sonar's  classification  sector. 
Note  this  only  uses  the  parameter  classification  distance. 


B.5.19  Update  MCMV  Position 

Updates  the  MCMV's  position  by  adding  a  randomly-generated  value  from  a  gaussian 
distribution  whose  standard  deviation  is  given  by  the  navigational  error.  The  MCMV's 
current  position  is  stored  for  graphical  output. 


B.5.20  Check  Damage  MCMV 

Checks  whether  the  MCMV  has  passed  through  a  mine’s  damage  radius  and  has  been 
damaged. 

B.5.21  Update  ROV  Position 

Updates  the  ROV's  position.  The  ROV  position  is  stored  for  graphical  output. 


B.5.22  Initialise  Encounter 
Sets  all  statistical  variables  to  zero. 


B.6  Routines  of  MH_Res 

B.6.1  Initialise  Results 

Initialises  the  results  before  running  the  simulation 
B.6.2  MHunt  Results 

Prints  statistical  variables  each  10%  of  total  replications  completed.  These  include  no. 
of  mines  in  field,  no.  detected,  no.  classified  etc. 

B.6.3  Print  MOES 

Calculates  then  prints  measures  of  effectiveness  derived  from  the  simulation.  These 
can  optionally  be  printed  to  a  file. 
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B.7  Routines  of  PC_Graph 
B.7.1  Write  Graphics  File 

Writes  data  for  object  positions  and  MCMV  and  ROV  movements  for  future  graphics 
processing. 

B.8  Module:  MH_Sonar 

B.8.1  Detect  Mile  Sonar  Probs 

Determines  whether  a  contact  is  detected  by  using  the  full  sonar  probability  data. 

B.8.2  Reduction  Factor  (Function) 

Calculates  the  reduction  in  detection  probability  experienced  at  the  edge  of  the  sonar 
sector. 

B.8.3  Prob  Detect  (Function) 

Determines  the  probability  at  a  given  range  using  linear  interpolation. 

B.9:  Module:  MH_Rand 

B.9.1  Gaussian 

Returns  a  random  number  selected  from  a  Gaussian  distribution. 

B.9.2  Init  Poisson 

Iiutialises  the  Poisson  distribution  streams. 

B.9.3  Poisson  (Function) 

Selects  a  random  number  from  a  given  Poisson  distribution  which  has  been  initialised 
by  Init  Poisson. 
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B.9.4  RandVal  (Function) 

Returns  a  uniform  random  number  -  calls  Randex  which  uses  double  precision. 

B.9.5  SRandIni 

Initialises  a  given  number  of  independent  random  number  streams. 

B.9.6  RandEx  (Function) 

Returns  a  uniform  random  number  from  a  given  stream. 

B.9.7  Ifactor  (Function) 

Fimction  used  by  Randex. 

B.9.8  LongMod  (Function) 

Function  used  by  Randex. 

B.IO  Module:  MH_Aux 

B.10.1  ClrScr 
Subroutine  to  clear  screen. 

B.10.2  Convert  Time 

Converts  time  in  minutes  to  hours  and  minutes. 

B.10.3  UpDateTime 
Updates  the  simulation  time. 

B.10.4  Reset  Minefield 

Sets  the  munbers  of  mines  and  non-mines  from  given  Poisson  distributions. 
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B.10.5  Set  Mile  Positions 

Sets  the  positions  of  the  mines  and  non-mines  in  the  field. 

B.10,6  Initialise  Mile  Attributes 

Initialises  mile  attribute  flags  such  as  detected  status. 

B.10.7  Normal  (Fimction) 

Returns  a  random  number  selected  from  a  probability  distribution  with  a  given  mean 
and  standard  deviation. 

B.10.8  SD  (Function) 

Calculates  standard  deviation  of  each  result  given  the  statistics  and  the  number  of 
replications. 

B.10.9  Gamma  (Function) 

Generates  random  value  from  gamma  distribution. 

B.10.10  ErLang  (Function) 

Generates  random  value  from  Erlang  distribution  (not  used  in  current  version). 

B.10.11  Rnd  (Fimction) 

Not  used  in  current  version. 

B.ll  Module:  MH_PC 

These  modules  mimic  VAX  FORTRAN  routines  by  using  calls  to  Microsoft  Fortran 
routines. 

B.11.1  Str$Upcase 

Converts  a  character  string  to  upper  case. 
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B.11.2  Secnds  (Function) 

Returns  time  in  seconds. 

B.11.3  Date 

Returns  date  as  a  character  string. 

B.12  Include  Common  Blocks 

B.12.1  Batc.cmn 

Contains  the  battery  charger  variables. 

B.12.2  Control.cmn 

Contains  flags  controlling  the  simulation  operation. 

B.12.3  Files.cmn 

Contains  names  for  input  and  output  files. 

B.12.4  Interact.cmn 

Contains  sonar  and  mine  interaction  parameters. 

B.12.5  MCMV.cmn 
Contains  MCMV  parameters. 

B.12.6  MDC.cmn 

Contains  Mine  Disposal  Charge  parameters. 

B.12.7  Mfield.cmn 


Contains  minefield  parameters. 
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B.12.8  MHunt.cmn 

Contains  variables  used  by  event  management  routines. 

B.12.9  Rand.cmn 

Contains  random  number  parameters. 

B.12.10  Results.cmn 

Contains  results  -  measures  of  effectiveness  for  minehunting. 

B.12.11  ROV.cmn 
Contains  ROV  parameters. 

B.12.12  Running.cmn 

Contains  intermediate  statistics  such  as  mines  detected  etc. 

B.12.13  Sonar.cirm 

Contains  sonar  performance  data. 

B.12.14  Tactics.cmn 
Contains  tactics  parameters. 

B.12.15  Block  Data :  BLKDTl 

This  contains  default  values  for  reaction  times,  battery  chargers,  no.  of  batteries,  max 
no.  of  contacts,  no.  of  ROVs  and  types  of  ROVs. 
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Annex  C:  Flowcharts  for  Processes  in  MHUNT  Model 


C.l  MCM  Process 

This  section  contains  the  key  sequences  of  events  undergone  by  the  MCMV  during  a 
minehunting  operation.  These  are  (a)  contact  detection,  (b)  contact  classification,  (c) 
identification,  and  (d)  mine  disposal.  Figure  C.l  shows  the  whole  sequence  of  events 
for  contact  investigation.  Briefly,  when  a  contact  is  encountered  the  detection  method 
is  set,  the  detection  of  the  contact  is  checked,  then,  if  a  detection  is  made,  the  contact  is 
classified  and  prosecuted  if  identified  as  a  mine.  Following  this  the  MCMV  returns  to 
the  track. 


Figure  C.l:  Flowchart  of  MCM  Process 
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C.1.1  Detection  using  Sonar  probabilities 


There  are  two  options  for  sonar  detection  -  either  sonar  cumulative  probabilities  as  a 
function  of  range  can  be  read  from  a  file  or  a  fixed  probability  for  the  whole  sonar 
sector  defined  by  the  detection  range  and  sector  angle  can  be  used.  In  the  first  of  these 
the  MCMV  is  moved  along  a  set  of  ranges  towards  the  contact  imtil  detection  has 
occurred  or  until  the  contact  has  passed  out  of  the  sonar's  detection  sector.  If  there  is  a 
possible  contact  in  the  sonar  "shadow"  at  the  start  of  a  track  (the  region  outside  the 
sonar's  detection  sector  that  would  have  been  insonified  had  the  sonar  been  operating 
before  the  start  of  the  track)  it  is  also  assumed  that  this  object  can  be  detected.  In  this 
case  only  one  chance  is  allowed  for  contact  detection. 


Figure  Cl:  Flowchart  of  sonar  detection  subprocess 
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C.1.2  Detection  using  Fixed  probabilities 

If  this  option  is  selected  a  fixed  value  of  detection  probability  is  applied  throughout  the 
detection  sector.  A  check  is  first  made  as  to  whether  the  object  is  within  tiie  sonar 
sector.  If  it  is  then  a  check  is  made  as  to  whether  it  is  detected,  using  random 
sampling.  Alternatively  if  the  next  object  in  the  track  is  outside  the  sector,  the  MCMV 
is  moved  along  the  track  tmtil  the  contact  is  within  this  sector  and  detection  is  checked. 
If  this  object  is  outside  the  detection  width  the  object  is  deemed  undetectable  and  the 
next  object  in  the  track  is  investigated.  Again  it  is  assumed  that  an  object  in  the 
"shadow"  region  at  the  start  of  a  track  can  be  detected. 


Figure  C.3:  Flowchart  of  detection  subprocess  using  constant  rectangular 

probabilities. 
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C.1.3  Classification  of  a  Contact 

In  the  model  classification  is  a  simpler  process  than  detection.  It  is  assumed  that  the 
MCMV  manoeuvres  to  the  best  position  to  classify  the  object  (Event  29)  requiring  a 
randomly-determined  reaction  time  to  do  so.  The  contact  is  then  classified  as  either  a 
mine  or  non-mine  after  an  appropriate  reaction  time  (Event  4). 

The  classification  process  is  shown  in  Figure  C.4 


/Contact  ' 
range? 


Move  MCMV 
within  range 


Contact  classified 


'contact 
really  a 
\nine?/ 


^on-Mins  jvj 

classified  y - 

'^rrectlv/^ 


I  Non-mine  classified  as  mine 


^/MineN.  N 

■classified  \ - 

S^orrectly?/ 


Mine  classified  as  non-mine 


I  Mine  classified  as  mine 


Figure  C.4:  Flowchart  of  contact  classification  subprocess 
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C.1.4  Investigation  of  a  Possible  Mine 

When  a  contact  has  been  identified  as  a  possible  mine  the  MCMV  moves  to  the  hover 
position  (event  6),  deploys  the  ROV  (event  31)  which  relocates  the  contact  (event  7)  and 
makes  an  identification  (event  8).  If  the  contact  is  identified  as  a  mine  it  is  prosecuted 
by  laying  a  mine  disposal  charge  (event  9);  otherwise  the  ROV  is  recovered  to  the 
MCMV  (event  10).  Note  that  if  the  object  is  really  a  non-mine  but  is  identified 
incorrectly  as  a  mine  then  it  is  also  prosecuted  incorrectly  as  a  mine. 


Figure  C.5:  Flowchart  of  contact  investigation  subprocess 


53 


DSTO-TN-0003 


C.1.5  Mine  Prosecution 

When  a  mine  identification  has  been  made  (event  8),  the  ROV  lays  a  mine  disposal 
charge  (event  9)  and  is  then  recovered  to  the  MCMV  (event  10).  The  MCMV  is  moved 
to  the  safe  fire  position  and  the  disposal  charge  fired  remotely  after  the  arming  delay 
has  expired  (event  11). 


Figure  C.  6:  Flowchart  of  contact  prosecution  subprocess 
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C.2  Next  ROV  Process  (NR) 

This  process,  whose  flow  chart  is  shown  below  as  Figure  C.7,  is  basically  a  queueing 
system  which  interacts  with  the  battery  charger  process  via  the  system  variables 
(numbers  of  flat  and  charged  batteries)  and  with  the  spare  ROV  (SPROV)  process  via  a 
message  (event  22  directly  executes  event  19  (decision  on  which  ROV  to  use  in  the  next 
ROV  operation)).  It  implements  a  heuristic  rule  for  deciding  which  ROV,  i.e.  the 
current  SPROV  or  the  current  next  ROV  (NEROV),  to  use  in  the  next  ROV  operation. 
This  decision  is  made  as  soon  as  an  ROV  is  recovered  after  an  ROV  operation,  the 
NEROV  then  being  in  the  state  of  waiting  for  a  decision  on  the  new  NEROV  (MD). 
The  decision  rule  is  as  follows: 

a.  If  the  current  SPROV  does  not  have  an  installed  battery,  it  becomes  the  new 
NEROV.  This  is  a  plausible  rule  because  the  current  NEROV,  which  has  just  been 
recovered,  will  probably  need  to  have  its  battery  removed  before  its  next  operation, 
and  the  current  SPROV  has  already  had  this  done,  and  will  probably  be  already 
undergoing  turnaround;  and 

b.  If  the  current  SPROV  has  an  installed  battery,  the  new  NEROV  will  be  chosen  as  the 
one  with  the  greatest  battery  life  remaining.  As  both  ROVs  have  installed  batteries 
in  this  case,  the  rule  is  plausible.  The  current  NEROV  may  need  to  have  a  new 
MDC  installed,  however  this  eventuality  was  not  taken  into  account  in  formulating 
the  rule. 

Whether  or  not  the  current  SPROV  becomes  the  new  NEROV  and  vice  versa,  the 
remainder  of  NR  is  concerned  with  the  NEROV  turnaround  process.  If  the  ROVs  have 
been  interchanged,  and  the  new  NEROV  has  a  fully  charged  battery  installed,  it  is 
possible  for  the  NEROV  to  transition  directly  to  the  state  of  waiting  for  the  next  mine 
classification  event  (WME).  Immediately  after  this  event  occurs,  the  MCMV  enters  the 
wait  for  NEROV  (WRO)  state  and  the  assemble  event  5  (ROV  becomes  available)  is 
executed. 

Because  of  the  possibility  that  the  ROVs  have  been  interchanged,  the  state  of  the 
NEROV  could  be  waiting  for  a  charged  battery  (WRB2)  or  in  turnaround  (TA2),  and 
this  has  to  be  checked  before  any  further  events  are  executed.  If  the  NEROV  is  waiting 
for  a  battery,  the  number  of  charged  batteries  is  checked  and  if  positive  event  23 
(battery  arrives)  is  executed,  signifying  the  start  of  turnaround  for  the  NEROV. 
Otherwise  it  remains  in  the  wait  state  WRB2.  If  the  NEROV  is  in  state  TA2,  it  remains 
in  this  state  until  the  turnaround  reaction-time  is  up  and  event  24  (ROV  turnaround 
finishes)  executes.  The  NEROV  then  has  a  fully  charged  battery  and  moves  to  state 
WME  to  await  a  mine  classification  event. 

If  the  ROVs  have  not  been  interchanged,  the  NEROV  may  or  may  not  have  a  flat 
battery  installed,  and  this  must  be  checked.  If  the  NEROV  has  a  flat  battery  installed,  it 
must  be  removed,  the  pool  of  charged  batteries  decremented,  and  the  pool  of  flat 
batteries  in  the  battery  charging  system  incremented.  If  the  NEROV  does  not  have  a 
flat  battery  installed,  it  must  be  in  state  WRB2  waiting  for  a  charged  battery  to  arrive 
(event  23)  and  this  event  must  be  placed  on  the  wait  list.  Event  23  generates  an  ROV 
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turnaround  time,  moves  NR  into  the  TA2  state  and  schedules  event  24.  When  event  24 
executes,  NR  moves  into  state  WME  as  already  described. 


Figure  C.7:  Flowchart  for  Next  ROV  Process 
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C.3  Spare  ROV  Process  (SR) 

This  process,  whose  flow  chart  is  shown  below  as  Figure  C.8,  is  basically  a  queueing 
system  which  interacts  with  the  battery  charger  process  via  the  system  variables 
(number  of  flat  and  charged  batteries)  and  with  the  next  ROV  (NEROV)  process  via  a 
message  (event  22  directly  executes  event  19  (decision  on  which  ROV  to  use  in  the  next 
ROV  operation)).  The  decision  rule  for  deciding  which  ROV,  i.e.  the  current  spare 
ROV  (SPROV)  or  the  current  NEROV,  to  use  in  the  next  ROV  operation  is  described  as 
part  of  the  NEROV  process.  If  the  current  SPROV  becomes  the  new  NEROV  and  vice 
versa,  an  "ROV  interchanged"  flag  is  set  and  checked  as  soon  as  the  SPROV  process 
begins.  As  event  19  is  directly  executed,  the  SPROV  can  be  in  any  one  of  three  states 
when  it  occurs:  waiting  for  a  decision  on  the  next  ROV  (WDS),  waiting  for  a 
replacement  battery  (WRBl)  or  in  turnaround  (TAl).  If  the  ROVs  have  not  been 
interchanged,  the  SPROV  undergoes  a  self-transition,  i.e.  its  state  is  imchanged. 

If  the  ROVs  have  been  interchanged,  the  new  SPROV  will  have  just  completed  an 
operation,  and  so  will  have  a  battery  installed.  This  is  tested,  and  if  fully  charged 
(remaining  battery  life  above  a  threshold),  the  SPROV  enters  the  wait  state  (WDS).  If 
the  installed  battery  is  flat,  it  must  be  removed,  the  pool  of  charged  batteries 
decremented,  and  the  queue  of  flat  batteries  and  the  number  of  batteries  in  the  battery 
charging  system  incremented.  The  SPROV  then  enters  the  wait  state  (WRBl)  and  puts 
a  battery  arrival  (event  20)  on  the  wait  list.  In  this  state  the  number  of  charged 
batteries  is  checked  and  if  positive  event  20  is  executed,  signifying  the  start  of 
turnaround  for  the  SPROV.  Otherwise  it  remains  in  state  WRBl.  Event  20  generates 
an  ROV  turnaround  time,  moves  SR  into  the  TAl  state  and  schedules  the  finish  of  the 
SPROV  turnaround  (event  21).  When  event  21  executes,  the  state  of  the  MCMV 
process  is  checked  to  determine  whether  SR  becomes  idle.  If  minehimting  is  finished 
(MCMV  process  in  states  return  to  port  (RP)  or  wait  for  other  processes  to  end  (WCE)) 
SR  enters  its  idle  state  (14).  A  check  is  then  made  as  to  whether  both  battery  chargers 
are  idle,  and  if  so  the  assemble  event  25  (minehimting  cycle  ends)  is  executed 
immediately. 
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Figure  C.8:  Flowchart  for  Spare  ROV  Process 
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C.4  Battery  Charger  Process  (BC) 

This  process,  whose  flow  chart  is  shown  below  as  Figure  C.9,  is  a  simple  queueing 
system.  The  same  process  describes  both  battery  chargers  if  there  are  two.  If  the  BC  is 
waiting  for  a  battery  to  arrive  (state  (WFB))  the  number  of  flat  batteries  in  the  queue  is 
checked,  and  if  positive  event  17  (battery  charger  starts)  is  executed.  This  decrements 
the  battery  queue  length,  generates  a  time  to  charge  the  battery,  moves  BC  to  the 
charge  battery  (CB)  state,  and  schedules  event  18  (battery  charging  finishes).  Event  18 
is  then  executed  after  a  reaction-time.  This  decrements  the  number  of  batteries  in  the 
battery  charging  system,  increments  the  number  of  charged  batteries  and  either 
schedules  another  event  18,  leaving  BC  in  state  CB,  if  there  is  a  queue  of  flat  batteries; 
returns  BC  to  state  (WFB)  and  puts  another  event  17  on  the  wait  list,  if  there  are  no  flat 
batteries  and  minehunting  has  not  finished  (MCMV  Process  in  states  return  to  port 
(RP)  or  wait  for  other  processes  to  end  (WCE));  or  puts  BC  in  its  idle  state  (13)  if  there 
are  no  flat  batteries  and  minehunting  has  finished.  When  BC  enters  its  idle  state,  a  test 
is  made  of  whether  the  assemble  event  25  (minehunting  cycle  ends)  can  be 
immediately  executed.  The  conditions  for  this  are  that  the  Spare  ROV  Process  (SR)  is 
idle  (state  14)  and  the  other  battery  charger,  if  any,  is  not  operating,  i.e.  either  waiting 
or  idle. 
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Figure  C.9: 


Flowchart  for  Battery  Charger  Process 
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Annex  D:  Additional  Output  from  MHUNT  Model 

This  Annex  contains  details  of  the  additional  outputs  that  can  be  obtained  from  the 
MHUNT  model:  the  event-state  trace  and  the  graphical  file  output.  These  are 
described  in  the  following  sections. 

D.l  Event-State  Trace 

The  event-state  trace  is  an  optional  output  from  single  replication  nms  of  the 
simulation.  An  example  of  part  of  an  event-state  trace  is  shown  below  as  Figure  Dl, 
with  explanations  of  each  of  the  different  types  of  output  given  in  boxes.  Each  event 
trace  lists,  from  left  to  right,  the  time  the  event  occurs,  the  event  name,  and  the  value  of 
each  event  pointer  element.  All  simultaneous  events  are  listed,  followed  by  a  state 
trace,  with  abbreviated  state  names  as  shown  on  the  state  transition  diagram,  for  that 
time.  The  main  system  variables  are  also  listed  after  the  state  trace. 

The  event-state  trace  is  useful  for  verifying  that  the  program  operates  as  specified  by 
the  directed  graph,  and  for  debugging.  Once  the  model  has  been  verified  and 
validated,  the  program  can  be  rim  in  event-state  trace  mode  to  better  imderstand  the 
actual  system  operation. 


BEGIN  OPERATION  FOR  REPLICATION  1 


NO  OF  ROVS  :  2  TYPE  OF  ROV  :  B 

NO  OF  BATTERY  CHARGERS :  2  NO  OF  BATTERIES  :  3 


number  (1  or  2) 
type  (battery(B)  or  cable  (C)) 
number  of  battery  chargers  (1  or  2) 
total  number  of  batteries  (integer) 


0:  .0  LEAVE  FOR  OP  AREA 
0:  .0  TO  WME 


EVTNUM=1  PROC=l 


NCM  =  0  NBATSE  =  3  NBATQ  =  0  NERONO  =  1 
SPRONO  =  2  BATLRNE  =  90.0  BATLRSP  =  90.0 
ITRACK  =  0JRUN  =  0 


f 

DUPL=0 


) 


state  trace  at  time  0 
process  1:  transit  to 
operational  area 
process  5:  wait  for  mine 
/ent 


r 

system  variables  at  time  0 
no  of  contacts  (mine);  0 
no  of  serviceable  batteries:  3 
no  of  batteries  in  queue:  0 
next  ROV  serial  number:  1 
spare  ROV  serial  number:  2 
next  ROV  battery  life  remaining:  90 
spare  ROV  battery  life  remaining:  90 
track#  0 
rrm  #  (on  track):  0 
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3:17.1  ARRIVE  AT  OP  AREA  EVTNUM=2  PROC=  1  DUPL=  0 
3:17.1  START  HUNTING  ON  TRACK  EVTNUM=26  PROC=l  DUPL=0 

3:17.1  RESUME  HUNTING  ON  TRACK  EVTNUM=27  PROC=  1  DUPL=0 


} 


I’all  events 
|occurring  at  the| 
isametime 


i 


3:17.1  SC  WFB  WFB  WDS  WME 

NCM  =  0  NBATSE  =  3  NBATQ  =  0  NERONO  =  1 
SPRONO  =  2  BATLRNE  =  90.0  BATLRSP  =  90.0 
ITRACK  =  1 JRUN  =  1 


■:State  trace  at  time  3  min  17.1  sec 
f  process  1:  search  for  contact 
liprocess  2:  not  operating 
Iprocess  3:  (duplicate  1)  wait  for  battery 
liprocess  3:  (duplicate  2)  wait  for  battery 
Iprocess  4:  wait  for  a  decision  on  next  ROV 
|iprocess  5:  wait  for  a  mine  classification  event 


3:29.2  START  CONTACT  DETECTION  EVTNUM=3  PROC=  1  DUPL=0 
3:29.2  SC  WFB  WFB  WDS  WME 

NCM  =  0  NBATSE  =  3  NBATQ  =  0  NERONO  =  1 
SPRONO  =  2  BATLRNE  =  90.0  BATLRSP  =  90.0 
ITRACK  =  1  JRUN  =  1 


3:30.9  END  CONTACT  DETECTION  EVTNUM=30  PROC=  1  DUPL=0 
3:30.9  CC  WFB  WFB  WDS  WME 

NCM  =  0  NBATSE  =  3  NBATQ  =  0  NERONO  =  1 
SPRONO  =  2  BATLRNE  =  90.0  BATLRSP  =  90.0 
ITRACK  =  1  JRUN  =  1 


Figure  D1 :  Part  of  Event-State  T race 


D.2:  Graphical  Output 

The  MHUNT  model  produces  an  output  file  consisting  of  information  which 
graphically  represents  the  events  that  occurred  during  a  simulated  minehunting 
operation.  This  output  file  is  produced  by  the  'Write_Graphics_File'  subroutine  and 
contains  the  following  information: 

(1)  Minefield  data  -  dimensions  of  the  field. 

(2)  Tactical  data  -  track  geometry  and  tactic-type. 

(3)  Mine  and  (4)  non-mine  data.  These  define  the  number,  position  and  status  of  three 
parameters:  detection,  classification,  and  identification  for  each  mine  and  non-mine. 

(5)  MCMV  data.  These  define  the  total  number  of  events  and,  for  each  MCMV  event, 
the  MCMV  position  recorded  when  each  event  occured. 
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(6)  ROV  data  These  define  the  total  number  of  ROV  events  and,  for  each  ROV 
event,  the  ROV  position  recorded  when  each  event  occurred. 

Figure  D.2  show  an  edited  output  file  produced  by  the  program. 

This  output  file  can  be  read  into  a  Visual  Basic  program.  This  system  uses  Visual 
Basic's  graphical  capabilities  to  draw  the  minefield,  place  the  mine  and  non-mines,  and 
show  the  path  of  both  the  MCMV  and  the  ROVs.  The  locations  of  the  mines  and  non¬ 
mines  can  be  indicated  by  a  key  set  of  symbols  to  reflect  the  detection,  classification 
and  identification  of  the  mines  and  non-mines. 


****  MINEFIELD  DATA  -  Length,  width,  depth 
20386.000000  1000.000000  30.000000 

tactical  data 

1  #####  No.  of  tracks 

500.000000  O.OOOOOOE+00  1000.000000  0 

MINIMUM  EFFORT 
NO 


mine  data  **** 


3 

#####  No.  of  mines 

No. 

xpos 

ypos 

detect 

classif. 

identif. 

1 

15746.39 

979.79 

T 

M 

M 

2 

15520.89 

721.77 

T 

M 

M 

3 

17055.83 

980.93 

T 

M 

M 

5t-5f5f3f3f 

NON-MINE  DATA 

10 

#####  No.  of  non-mines 

No. 

xpos 

ypos 

detect 

classif. 

identif. 

1 

476.44 

949.12 

T 

M 

N 

2 

8242.33 

309.21 

T 

N 

U 

3 

10806.32 

641.15 

T 

N 

U 

4 

16543.43 

56.49 

F 

U 

u 

5 

18585.88 

294.12 

T 

N 

u 

6 

10828.41 

941.00 

T 

N 

u 

7 

2487.79 

156.96 

T 

N 

u 

8 

11403.32 

53.96 

T 

N 

u 

9 

8984.45 

179.53 

T 

N 

u 

10 

9602.63 

120.32 

T 

N 

u 
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MCMV  DATA 

170  ####  No  of  MCMV  events 

Event  no  xpos  ypos 


1 

1.69 

506.02 

2 

5.64 

490.70 

3 

3.24 

495.85 

4 

296.82 

778.51 

163 

18470.47 

486.34 

164 

19764.84 

123.13 

165 

19753.72 

505.52 

166 

19760.42 

509.33 

167 

20115.98 

583.30 

168 

20117.77 

499.21 

169 

20113.49 

500.81 

170 

20386.67 

493.02 

***»  poV  DATA  **** 


10  ####  No.  of  ROV  events 


ROV  Event  no 

xpos 

ypos 

MCMV  Event  no. 

1 

408.66 

877.71 

5 

2 

476.44 

949.12 

5 

3 

4129.56 

875.38 

42 

4 

4197.00 

949.71 

42 

5 

15430.25 

714.27 

124 

6 

15520.89 

721.77 

124 

7 

15665.32 

917.40 

129 

8 

15746.39 

979.79 

129 

9 

17030.26 

887.88 

149 

10 

17055.83 

980.93 

149 

Figure  D.2:  An  output  file  produced  by  the  'Write_Graphics_File'  subroutine'. 
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Annex  E:  Symbols  and  Abbreviations 


S5anbol/Abbreviation 

Meaning 

A 

Mine  Actuation  Width 

AMRL 

Aeronautical  and  Maritime  Research  Laboratory 

B 

Mine  Actuation  Probability 

Bd 

Probability  of  Damage  by  Mine 

C 

Channel  Width 

CL 

Mean  Clearance  Level 

Cli 

Clearance  Level  (Replication  i) 

d 

Track  Spacing 

5 

MCMV's  Hover  Distance 

D 

Detection  Width 

daU 

di 

Total  Number  of  Mines  Disposed  (all  replications) 
Number  of  Mines  Disposed  (Replication  i) 

DLL 

Dynamic  Link  Library 

Edge  Reduction  Factor 

J 

Number  of  Runs  per  Track 

L 

Track  Length 

M 

Number  of  Mines  in  Field 

MCM 

Mine  Countermeasures 

MCMV 

Mine  Countermeasures  Vessel 

MCS 

Minefield  Clearance  Simulation 

MDC 

Mine  Disposal  Charge 

MHC 

Mine  Hunter  Coastal 

MOE 

Measure  of  Effectiveness 

MWSC 

Mine  Warfare  Systems  Centre 

N 

Number  of  Tracks 

NAG 

Numerical  Algorithms  Group 

naU 

Total  Number  of  Mines  in  Field  (all  replications) 

Hi 

Number  of  Mines  in  Field  (Replication  i) 

6 

Sector  Angle 

R 

Number  of  Replications 

RAN 

Royal  Australian  Navy 

ROV 

Remotely  Operated  Vehicle 

a 

Navigation  Error 

STD 

State  Transition  Diagram 

TMSS 

Total  Mine  Simulation  System 

Tp 

Mine  Prosecution  Time 

V 

Mean  Speed  of  Advance  (of  MCMV) 
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Minehunting  is  a  complex  process  involving  detection  and  classification  of  contacts  using  sonar  and  the 
subsequent  identification  and  disposal  of  mines  generally  using  a  remotely  operated  underwater  vehicle  (ROV). 
However,  making  suitable  assumptions,  minehunting  can  be  approximated  by  a  series  of  connected  events  and 
thus  made  amenable  to  modelling  using  the  technique  of  discrete-event  simulation.  In  this  report,  a  discrete- 
event  minehunting  simulation  model  is  described  together  with  instructions  for  its  operation.  The  model  can  be 
applied  to  evaluate  the  effectiveness  of  minehunting  systems  for  a  given  operational  scenario  and  also  to 
investigate  new  concepts. 
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